Override a schedule-layer vs a schedule (pause a rotation)

#1

Most of our on-call rotations don’t change very often, i.e. it’s the same users in the same order, only varying as team members come and go.

Team members are scheduled to be on-call depending on their order in the rotation, not on a fixed schedule (‘every fourth week’) necessarily, which fits with their idea of fairness.

While the rotations are fairly constant, the corresponding PagerDuty schedule for the rotation changes more often, as a rotation is paused to accommodate random events such as holidays (with those from other locales pitching in to cover), personal time off, key business events, etc.

Using the Override feature, we can override the rotation to cover these random events, but must then edit the schedule-layer (we use the PD Terraform provider on the API) to restore the rotation after the override, so that the rotation picks up where it left off, at the start of the override.

We would like to have a feature, to override within an existing layer (i.e., within a rotation), vs as a separate layer in the schedule. Or even more simply, override a schedule-layer vs override a schedule.
With this feature, we could in effect pause a rotation, so that the rotation resumes where it left off, at the start of the pause.

For example:

Rotation

  1. User1
  2. User2
  3. User3
  4. User4

Schedule (Layer)

Week User
1 User1
2 User2
3 User3
4 User4
5 User1
6 User2

With User4 on PTO in Week 4 (ignoring who would fill the gap)

With the existing override-a-schedule feature

Week User
1 User1
2 User2
3 User3
4 —
5 User1
6 User2

With the proposed override-a-schedule-layer feature

Week User
1 User1
2 User2
3 User3
4 —
5 User4
6 User1
#2

You can achieve this using the PagerDuty add-on product oncallscheduler.com. It’s not exactly the feature you describe, but accomplishes the same goal of ensuring fairness when some shift have been removed from being the responsibility of a PagerDuty schedule layer.
You do this in oncallscheduler.com by:

  1. using its normal functionality for fair scheduling, letting the scheduling happen based on each rotation members’ credit balance.
  2. For shifts that’ll be covered by another geographic location, you assign those shifts to a not-real rotation member (e.g. NotAssigned@adaptavist.com). No real member will then get credit for those shifts. But the regular scheduling will continue in a fair way after that shift.
    We (on the oncallscheduler.com team) have considered making this “NotAssigned@…”) be a more explicit product feature. Perhaps we will. So far we have left it as something customers can enter, since it is a bit of an unusual use case, and we don’t want to add things to the mainstream UI unless they are frequently used.